- Identificación, Autenticación y Autorización
Videos:
https://open.fing.edu.uy/courses/fsi/6/
https://open.fing.edu.uy/courses/fsi/7/
https://open.fing.edu.uy/courses/fsi/8/
Diapositivas:
[[iaa.pdf]]
[[politicas y modelos de seguridad.pdf]]
[[politicas y modelos de seguridad ii.pdf]]
Usuarios y Autenticación
Autenticación: es el proceso de verificar una (pretendida) identidad.
Dos razones para autenticar a los usuarios:
- La identidad del usuario es un parámetro para la decisión de control de acceso.
- La identidad del usuario es registrada cuando se hace el logging de eventos relevantes para la seguridad en la auditoría.
No siempre es necesario (o deseable) basar el control de acceso en la identidad de cada usuario, aunque sí es esencial loguear identidades para poder auditar.
> Verificación de Identidades #parcial
Se debería usar una o más de los siguientes:
- Algo que se sabe (ej. password)
- Algo que se tiene (ej. badge, token, smart card)
- Algo que se es (ej. Huella digitales, ADN, iris)
- Donde se está (ej. Usando una terminal particular)
Proceso de Autenticación
Son varios pasos:
- Obtener la información de autenticación de una entidad.
- Analizar los datos.
- Determinar si la información de autenticación es efectivamente asociada a la entidad.
> Sistema de Autenticación formal #parcial
Tupla (A, C, F, L, S)
- A: información que prueba la identidad.
- C: información almacenada en la computadora y que es usada para validar la información de autenticación.
- F: función de complementación
- L: funciones que prueban la identidad.
- S: mecanismos que le permiten a la entidad crear o alterar información en A o C.
> Ejemplo #parcial
Mecanismos de autenticación
Passwords
- En general, son una secuencia de caracteres o de palabras.
- Si son palabras, se le dice pass-phrases.
- Una password es información que confirma la identidad de una entidad asociada.
Almacenamiento de passwords
- Texto claro.
Si el archivo es comprometido, todas las passwords son reveladas. - Texto cifrado.
Requiere tener las claves de encriptado/desencriptado en memoria.
Reduce al problema previo (pues esas claves estarían en texto claro).
Entonces cómo protejo las password?
Almacenar el one-way hash.
Si el archivo es comprometido, el atacante igual tiene que invertir el hash o adivinar las passwords.
- La password es hasheada y luego almacenada. La misma nunca se "deshashea".
- Para que sea útil, debe ser difícil invertir la password almacenada.
> Análisis de un ataque de usurpación de identidad #parcial
> Ejemplo en sistema de autenticación UNIX #parcial
Se hashean las passwords en un string de 11 caracteres usando una de 4096 funciones de hash existentes.
Sistema:
- A = { strings de 8 caracteres o menos }
- C = { 2 char (hash id) || 11 char (hash) }
- El 2 char identifica la función de hash usada.
- F = { 4096 versiones de DES modificado }
- L = { login, su, … }
- S = { passwd, nispasswd, passwd+, … }
Explicación del ataque
Objetivo: encontrar
- Para algún
Hay dos formas de determinar si
- Enfoque directo: como indicado arriba, es posible si C es conocido por el atacante.
O sea, el atacante obtuvo (una parte) del archivo de los hash almacenados. - Enfoque indirecto: como
Prevenir ataques
Se podría esconder
- Previene ataques obvios
Ejemplo: UNIX/Linux shadow password files
Esconde
Sino, bloquear el acceso a las
- Previene que el atacante puede enterarse de si la password ha sido adivinada.
Ejemplo: prevenir logins a una determinada cuenta desde la red
Previene conocer resultados de
> Ataque de Diccionario #parcial
Ensayo y error a partir de una lista de passwords potenciales.
> Tipo 1: el atacante conoce
También conocido como Off-line: el atacante conoce
> Tipo 2: el atacante conoce
También conocido como On-line: el atacante tiene acceso a las funciones en
Defenderse de Password Guessing
El objetivo siempre es maximizar el tiempo necesario para adivinar una password.
Fórmula de Anderson:
Entonces:
Para hallar cuánto demoraría en ejecutar un ataque offline, igualo la probabilidad a 1 y despejo
Salting
Objetivo: evitar ataques de diccionario diseñados para encontrar una password de cualquier usuario.
Método: perturbar la función de hash
- un param. para elegir la función de hash
- una param. que difiere para cada password (el salt o sal)
- Para determinar si el string s es la password de uno de n usuarios, el atacante tendría que ejecutar
Expiración de password
Forzar a los usuarios a cambiar passwords luego de un cierto tiempo.
Es importante darle tiempo a los usuarios y no apurarlos a elegir la nueva password.
Desafío-Respuesta
Los passwords tienen el problema de que son reusables. Si se comprometen, pueden volver a usarse en varios lugares (replay del password).
Una alternativa es que la password cambie cada vez que se usa.
Sea
El usuario y el sistema comparten una función secreta
Pass Algorithms
Desafío-respuesta con la función
Usualmente usado en conjunción con password fija y reusable.
Enfoques basados en claves públicas criptográficas
- A envía su desafío randómico
- B toma un nonce
- La firma
One-Time Passwords (OTP)
Passwords que pueden ser usadas exactamente una vez.
- Exige alta sincronización del usuario con el sistema.
- Generación de buenas passwords randómicas.
- Problema de distribución de password.
> S/Key de L. Lamport #parcial
Esquema de one-time password basado en ideas de L. Lamport.
- El usuario elige la semilla inicial k.
- El generador de claves calcula:
- Las passwords se van usando en orden inverso.
- Si se compromete una clave, la anterior no es calculable si
Mecanismos alternativos
Opciones alternativas de autenticación.
Algo que se sabe
El usuario tiene que conocer un secreto para ser autenticado.
Algo que se tiene
El usuario debe presentar un token físico para ser autenticado.
Quién se es
Esquemas biométricos de autenticación.
Qué se hace
La gente desarrolla mecánicamente tareas que son repetibles y específicas al individuo.
- Firmas manuscritas, sobre un dispositivo que mida atributos como velocidad y presión de escritura.
Donde se está
Cuando el usuario se loguea el sistema puede tomar también en cuenta dónde se encuentra.
Métodos múltiples
Combinación de múltiples mecanismos alternativos.
Ingeniería Social
Riesgos
- Explota vulnerabilidades del factor humano.
- Extrae información (pwds, datos personales, etc.) mediante falsos pretextos.
- Dispositivos de autenticación (generador de tokens, etc.) no siempre son aplicables o viables.
Contramedidas
- Administradores de sistemas y usuarios concientizados ante amenazas y riesgos.
- Política de seguridad de la información.
Resumen
- Autenticación no es (solamente) criptografía.
- Las passwords constituyen un mecanismo duradero.
- Los protocolos son muy importantes.
- Métodos de Autenticación pueden ser combinados.
- Una password o secreto no autentica a una persona, una autenticación exitosa sólo garantiza que la persona conoce el secreto.
- No hay forma de diferenciar un usuario legítimo de un intruso que ha podido acceder al secreto.
Autorización y Control de Acceso
Autorización: Es el proceso que determina (luego de su autenticación) a qué recursos de un sistema tiene acceso una identidad.
Control de Acceso
Control de acceso = Autenticación + Autorización
- Si s es una sentencia, autenticación responde la pregunta: quien dijo s?.
- Si o es un objeto, autorización responde la pregunta: quién tiene acceso a o?.
Sujetos, Principals, Objetos
IBAC (identity based access control)
- Sujetos actúan en representación de usuarios humanos, o principals.
- Acceso está basado en la asociación entre la identidad del usuario y el sujeto.
Alternativas
- Principal (políticas de seguridad): una entidad a la que se le puede otorgar acceso a objetos.
- Sujeto (sistemas operacionales que aplican una política): una entidad activa en un sistema IT.
Sujetos, Objetos, Operaciones
Objetos: archivos, memoria, impresoras, nodos en una red, etc.
Sujeto: un proceso que se ejecuta bajo una cierta identidad.
Una simple distinción entre entidad pasiva y activa.
Dos opciones para especificar control, estableciendo:
- Lo que un sujeto puede hacer.
- Lo que se puede hacer con un objeto.
Operaciones y Modos de Acceso
Operaciones de Acceso
Dependiendo del enfoque e interés, operaciones de acceso varían desde lectura y escritura de archivos a invocación de métodos en un sistema orientado a objetos.
Modos de Acceso
Nivel más elemental
- Observe: mirar el contenido de un objeto
- Alter: cambiar el contenido de un objeto
Casi todos las políticas son equivalentes a este modelo, pero es poco preciso y difícil de verificar.
Tipos de Permisos en Bell-LaPadula
Un poco más de complejidad:
- execute, append, read, write
write es Observe y Alter
Un archivo tiene que ser abierto (lectura, escritura) antes de que sea permitido el acceso. Acceso de escritura generalmente incluye acceso para lectura.
El SO puede utilizar archivos (programas) sin necesidad de abrirlos: execute no precisa observe ni alter.
SO actuales
Políticas de control de acceso son definidas en función de tres operaciones:
- read, write, execute
Aplicadas a directorios varía el significado.
> Propiedad de recursos (discrecional vs. mandatoria) #parcial
Quién está a cargo de establecer las políticas de seguridad?
- Se puede definir un propietario para cada recurso, y que sea el propietario quien decide quién puede acceder a ese recurso (discrecional).
- Una política que abarca todo el sistema establece los permisos de acceso (mandatoria).
La mayoría de los SO soportan el concepto de propietario de un recurso.
Estructuras de Control de Acceso
Establecer qué operaciones de acceso son permitidas.
Requerimientos:
- Que ayuden a expresar adecuadamente las políticas deseadas.
- Que permitan verificar que las mismas han sido correctamente formuladas.
Matriz de Control de Accesos (MCA)
Permisos de acceso pueden ser establecidos individualmente para cada sujeto y objeto.
> Capabilities #parcial
Permisos asociados a los sujetos.
Corresponde a una fila de la MCA.
Capabilities son asociadas con el control de acceso discrecional (DAC).
Una lista de capabilities es una clave, token o ticket que otorga al proceso la aprobación para acceder a un objeto dentro del sistema informático. El usuario es evaluado según una lista de capabilities antes de obtener acceso a un objeto específico.
Ejemplo
- S1: (edit.exe: execute; fun.com: execute, read)
- S2: (bill.doc: read, write; edit.exe: execute; fun.com: execute, read, write)
> ACL: Access Control Lists #parcial
Una ACL asocia los permisos de acceso a un objeto con el objeto mismo.
Corresponde a una columna de la MCA.
Característica de seguridad típica de SO comerciales.
Las ACL también son asociadas con el control de acceso discrecional (DAC).
Manejo de permisos asociado a cada sujeto individual es complicado: implementación de grupos.
El modelo Unix de CA se basa en simples ACLs que asignan permisos a los principals user, group, others.
Difícil determinar los permisos de un usuario, por ejemplo, para revocarlos.
Ejemplo (no UNIX)
- O1: (agustín: execute; root: execute, read)
- O2: (pepe: read, write; agustín: execute; root: execute, read, write)
Privilegios
Centrando la atención en las operaciones de acceso, los privilegios son conjuntos de permisos para la ejecución de las mismas.
Típicamente, privilegios son asociados con funciones de SO y están relacionados con actividades de administración de sistemas, backup, acceso al mail o a la red.
Privilegios pueden ser entendidos como una capa intermedia entre los sujetos y las operaciones.
> Fundamentos de la Seguridad Multinivel #parcial
Políticas existentes asignaban niveles de seguridad a documentos y clearances asociadas a usuarios determinaban a que documentos éstos podían acceder.
Las versiones mas elementales de políticas usaban una jerarquía linealmente ordenada de niveles: unclassified, confidential, secret, top secret.
Problema: con un orden lineal de niveles sólo se pueden expresar políticas muy limitadas.
El Reticulado de Niveles de Seguridad
La estructura algebraica que permite responder dos cuestiones:
- Dados dos objetos con diferente niveles de seguridad, cuál es el mínimo nivel de seguridad que debe poseer un sujeto para poder observar los dos objetos?
- Dados dos sujetos con diferente niveles de seguridad, cuál es el máximo nivel de seguridad que debe poseer un objeto para poder ser observado por los dos sujetos?
O sea, permite definir y validar políticas.
Def. de reticulado
Un reticulado
Ordenes parciales
Un orden parcial (
Def. de dominar
En seguridad se dice que
- El nivel de seguridad que es dominado por todo otro nivel se conoce como System Low.
- El nivel de seguridad que domina a todo otro nivel se conoce como System High.
> Reticulado need-to-know #parcial
Para poder definir políticas need-to-know (least privilege) que controlan el acceso a recursos de un proyecto específico se introdujo el siguiente reticulado de niveles de seguridad.
- Sea
- Sea
- Una etiqueta de seguridad es un par
El orden parcial de etiquetas de seguridad se define como:
Ejemplo
Políticas de seguridad
Para formular un política de seguridad se deben describir:
- Las entidades gobernadas por la política.
- La reglas que constituyen la política.
Modelos
Proceso de diseño y verificación:
- Especificación formal de la política que debe ser aplicada.
- Especificación de alto nivel del sistema de estudio y modelado de los mecanismos de seguridad.
- Verificación que la política es satisfecha por el modelo (prueba formal si alto nivel de aseguramiento es requerido).
Introducción
Discretionary Access Control Models (DAC)
[Bishop p.53] Si un *usuario individual puede setear un mecanismo de control de acceso* para permitir o denegar un acceso a un recurso, ese mecanismo constituye un control de acceso discrecional (DAC), también llamado un control de acceso basado en identidad (IBAC).
- Gobiernan el acceso de sujetos a objetos basándose en la identidad del sujeto, la identidad del objeto y los permisos de acceso.
- Cuando un access request (AR) es sometido al sistema, el mecanismo de control de acceso verifica si existe un permiso que autorice el acceso.
- Estos mecanismos son discrecionales ya que permiten que los sujetos puedan otorgarle a otros sujetos autorización de acceder sus propios objetos.
Ventajas
- Flexibilidad para especificar políticas.
- Provisto por todos los SOs y DBMS,
Desventajas
- No pueden controlar flujo de la información (ataques con Troyanos).
Mandatory Access Control Models (MAC)
[Bishop p.53] Cuando un mecanismo de un sistema controla acceso a un objeto y un individuo no puede alterar ese acceso, entonces el control de acceso es mandatorio (MAC) (ocasionalmente llamado control de acceso basado en reglas).
MAC especifica el acceso que los sujetos tienen sobre objetos basado en la clasificación de seguridad que se hace de esos sujetos y objetos.
Este tipo de seguridad también es conocido como multilevel security.
Modelo HRU (es DAC)
Para describir una instancia del modelo preciso:
- Un conjunto de sujetos
- Un conjunto de objetos
- Un conjunto
- Una matriz de control de acceso
- La entrada
Operaciones primitivas
El modelo incluye 6 operaciones primitivas para manipular el conjunto de sujetos, el de objetos y la matriz de acceso:
- enter
- delete
- create subject
- delete subject
- create object
- delete object
Comandos
- Los índices
- La condición de los comandos chequean determinados permisos de acceso.
- Si todas las condiciones se hacen verdaderas entonces se ejecuta la secuencia de operaciones básicas.
- Cada comando contiene al menos una operación.
- Los comandos que contienen exactamente una operación son llamados comandos mono-operacionales.
Ejemplo
Sistemas de protección
Un sistema de protección es:
- Un conjunto finito de permisos.
- Un conjunto finito de comandos.
Un sistema de protección es un sistema de transición de estados.
Estados
Un estado, es decir, una matriz de acceso, se dice que gotea (leaks) el permiso
si existe un comando que agrega el permiso en una entrada de la matriz de acceso que anteriormente no contenía ese permiso. Más formalmente, existen y tales que y, luego de la ejecución de , .
Nota: El hecho de que un permiso gotee no es necesariamente malo, muchos sistemas permiten a sujetos darle acceso a otros sujetos.
Estados seguros
- Definición 1: "acceso a los recursos sin el consentimiento del propietario es imposible" [HRU76].
- Definición 2: "un usuario debería ser capaz de saber si la acción que va a efectuar (por ejemplo, otorgar un permiso) puede provocar que el mismo gotee hacia sujetos no autorizados" [HRU76].
Safety
El problema que motiva la introducción de este concepto puede ser descrito de la siguiente forma:
"Suponer que un sujeto
Un ejemplo de sistema de protección unsafe
Asuma un sistema de protección con los siguientes dos comandos:
Suponer que el usuario Juan desarrolló un programa que él desea sea ejecutado por otros usuarios pero no puedan modificarlo.
El sistema anterior no es seguro respecto a esta política, considere la siguiente secuencia de comandos:
- Juan:
grant_execute (Juan, José, P1) - José:
modify_own_right (José, P1)
Resulta en una matriz de acceso donde la entradaé
Definición 'safe' y 'unsafe'
Dado un sistema de protección y un permiso
Definición alternativa
Un estado de un sistema de protección, o sea, su matriz
Teorema
Dada una matriz de acceso
Conclusiones
Los resultados sobre la decibilidad del problema de safety ilustran un principio importante, el principio de economía de mecanismos:
- Si uno diseña sistemas complejos que pueden solamente ser descriptos por modelos complejos, resulta muy difícil encontrar pruebas de safety de los mismos.
- En el peor caso (indecibilidad), no existe un algoritmo universal que verifica la seguridad del mismo para todas las posibles instancias del problema.
Problema de MAC: troyanos
Juan puede acceder al contenido de O1 indirectamente desde O2, ya que Ana podría leer y escribir todo su contenido.
Los modelos DAC no tienen capacidad para proteger datos contra Troyanos embebidos en programas de una aplicación.
Los modelos MAC fueron desarrollados para prevenir este tipo de acceso ilegal.
> Modelo Bell-LaPadula (es MAC) #parcial
Uno de los modelos de seguridad más difundidos:
- Seguridad de SO multi-usuario.
- Sistemas que procesan información clasificada de distintos niveles deberían implementar MLS.
- Los usuarios sólo deberían poder acceder a la información que están autorizados (clearance).
> El modelo, descripción breve #parcial
Formulado como una máquina de estados que captura aspectos de confidencialidad.
Los permisos de acceso se definen usando una matriz de control de acceso y etiquetas de seguridad.
Las políticas establecen que la información no puede fluir hacia niveles de seguridad inferiores a los del repositorio origen.
El modelo sólo considera el flujo que ocurre cuando un subject observa o altera un objeto.
> El Estado #parcial
Se desea utilizar el estado del sistema para verificar su seguridad, entonces el conjunto de estados del modelo debe capturar todas las instancias de sujetos que están accediendo a objetos y todos los permisos especificados.
Conjuntos base
- Conjunto
- Conjunto
- Conjunto
- Conjunto
Componentes
- Tabla de operaciones de accesos sucediendo actualmente.
- Matriz de permisos.
- Funciones de asignación de niveles de seguridad
-
-
-
-
El estado =
> Seguridad simple #parcial
- BLP define seguridad como una propiedad que cumplen los estados.
- MLS permite a un sujeto leer un objeto sólo si el nivel maximal de seguridad del sujeto domina al del objeto.
- Propiedad de Seguridad Simple (ss): Un estado
- Propiedad de Seguridad Simple (ss): Un estado
- Esta propiedad captura la política de confidencialidad no read-up.
Asume que el write es implícitamente también un read.
Desclasificación
- Sistemas donde sujetos son procesos
- No tienen memoria.
- Tienen acceso a objetos de memoria.
- Pueden actuar como canales leyendo un objeto y transfiriendo la información a otro objeto.
- Un atacante puede insertar un troyano en un objeto de alto nivel de seguridad y copiar información de objetos de alto nivel en objetos de inferior nivel de seguridad.
La propiedad *
BLP incluye una propiedad de no escritura hacia abajo pero que refiere al nivel de seguridad corriente del sujeto.
- La propiedad *: un estado
writeoappendel nivel corriente de seguridad del sujeto - Mas aún, si existe una tupla
readowrite.
Estado y Transición Seguros
Un estado
se dice que es seguro si satisface las propiedades ss, * y sd.
- Una transición del estado
- Transiciones deben preservar las propiedades de seguridad.
> Limitaciones y tranquility #parcial
Cuestionamiento de McLean al modelo BLP.
Supongamos un sistema con una transición que:
- Asigna a sujetos y objetos el nivel mínimo de seguridad.
- Asigna todos los permisos a cada entrada de la matriz de control de acceso.
Esta transición es segura según la definición de BLP, realmente lo es? - En contra de BLP: un sistema que puede degenerarse así no es seguro (McLean).
- A favor de BLP: si es un requerimiento del usuario la transición debe ser admitida, sino no lo debe ser (Bell).
Conclusión
- El punto central de esta discusión es una transición de estado que cambia los permisos de acceso.
- Estos cambios son admitidos en el marco general de BLP.
- Los autores consideraron sistemas donde los permisos de acceso son invariantes.
- La propiedad de que los permisos de acceso y los niveles de seguridad nunca son modificados es llamada Tranquility.
Modelo Chinese Wall
Aplicado a la prevención de conflicto de intereses.
Modela reglas de acceso en una consultora en la que sus analistas deben asegurar que no se generará conflicto de interés entre sus diferentes clientes.
Política de seguridad: ningún flujo de información puede causar un conflicto de interés.
> Conflicto de Interés #parcial
- En el mundo financiero un ejemplo es el del analista de mercado que trabaja para una institución financiera proveyendo servicios para negocios corporativos.
- Este analista debe preservar la confidencialidad de la información provista a él por el cliente, por lo tanto no puede trabajar para empresas si tiene conocimiento interno de los planes y estado de situación de una empresa competidora.
- Sin embargo el analista puede asesorar corporaciones que no están en competencia entre ellas así como poder manejar información general del mercado.
Política Chinese Wall
Dinámicamente establece los permisos de acceso de un usuario basado en los accesos que ya ha efectuado el mismo.
Información Sanitizada
Por lo tanto establecen que las restricciones de acceso pueden no ser aplicadas sobre información sanitizada.
La sanitización se realiza disfrazando la información de una corporación de forma de prevenir que se conozca la identidad de la misma.
Estado
-
Un conjunto de compañías C
-
Los sujetos (S) son los analistas, los objetos (O) son unidades de información
-
Objetos son organizados en 3 niveles
- Información
- Dataset (conjunto de datos de una compañía c)
- DS: O -> C (función que retorna el dataset de la compañía del objeto argumento)
- Clases de conflicto de interés (CoI)
- CoI: O ->
-
El nivel de seguridad de un objeto o es el par (CoI(o), DS(o)).
-
Información sanitizada es la que no contiene elementos sensibles. El nivel de seguridad es ({}, DS(o))
-
Historia de los accesos:
-
Políticas de seguridad
- Prevención de flujo de información directo (Regla Read)
- Regulación de acceso para escritura (Regla Write)
Prevención de flujo
> Prevenir que un sujeto sea expuesto a un conflicto de intereses #parcial
Si
- El objeto
- O si no la compañía de
Propiedad ss (regla Read)
Un sujeto
- DS(o) = DS(o'), o si se cumple que
- DS(o) ∉ CoI(o')
Flujo de información indirecto es todavía posible.
Comparación con Bell-LaPadula
La Política Chinese Wall es una combinación de elección libre y control mandatorio:
Inicialmente un sujeto es libre de acceder a cualquier objeto que él desee. Una vez que la elección inicial se ha hecho, una Chinese Wall es creada para ese usuario en torno al conjunto de datos a los que pertenece el objeto.
Flujo indirecto
La regla Read no previene flujo indirecto de información.
Considerar el siguiente caso:
- Consultor A tiene acceso a
- Comb. A y Banco A
- Consultor B tiene acceso a
- Comb. A y Banco B
Si a Consultor A se le permite leer Banco A y escribir en Comb A, él podría transferir información acerca de Banco A que puede ser leída por Consultor B.
Regulación de escritura
Acceso de escritura a un objeto
Propiedad * (regla Write)
Un sujeto
- DS(o) = DS(o'), o se cumple que
- CoI(o') = {}
El flujo de información es confinado al conjunto de datos de la compañia.
Conclusión
- La *propiedad ** no permite que información que no haya sido sanitizada pueda fluir hacia fuera del dataset.
- En contraste con BLP, donde la asignación de permisos de acceso es usualmente estática, en este modelo los permisos de acceso son reasignados en cada transición de estado.
> Modelo RBAC (Role Based Access Control) #parcial
Motivación
- Un problema importante al gestionar sistemas de envergadura es la complejidad que presenta la administración de la seguridad.
Cuando el número de objetos y sujetos es alto, el número de autorizaciones también tiende a ser muy alto. El costo computacional de gestionarlos crece. - El control a menudo está basado en las funciones de los usuarios más que en la propiedad de la información.
RBAC ha sido propuesto como un enfoque alternativo a DAC y MAC con el objetivo de simplificar la gestión de control de acceso y proveer soporte directo a la implementación de control de acceso basado en funciones de trabajo.
Idea
Roles representan funciones dentro de una organización y las autorizaciones son otorgadas a los roles en vez de a los usuarios (sujetos).
Los usuarios son entonces autorizados a “jugar” roles, y por lo tanto a adquirir las autorizaciones que le son otorgadas a esos roles.
Beneficios
Como los roles representan funciones organizacionales, un modelo RBAC puede directamente soportar políticas de seguridad de la organización.
> DAC vs. MAC vs. DBAC #parcial
- MAC controla acceso en función de etiquetas de seguridad.
- DAC controla acceso a un objeto en función de los permisos definidos para ese objeto por su propietario.
- RBAC es un componente independiente de control de acceso, que puede convivir sin problemas con DAC y/o MAC.
> Conceptos básicos y relaciones #parcial
Usuario
Es definido como un ser humano, una máquina, un proceso, un agente inteligente autónomo, etc.
Rol
Es una función dentro del contexto de una organización con una semántica asociada en relación a su autoridad y responsabilidad
Permiso
Es un modo de acceso que puede ser ejercitado sobre los objetos del sistema. Tanto los objetos como los permisos son dependientes del dominio.
Sesión
Es una instancia particular de una conexión de un usuario al sistema tal que define el sub-conjunto de roles activados por el usuario. En un momento dado, el usuario puede tener activadas varias sesiones concurrentemente.
Modelo NIST
Representa el primer paso hacia la definición del estándar del modelo RBAC.
https://security.stackexchange.com/a/169877
- RBAC0: Core
RBAC básico. - RBAC1: Hierarchical RBAC
RBAC jerárquico. Los roles están organizados como grafos, con permisos heredados. Sirve para implementar fácilmente políticas con estructuras de ese tipo. - RBAC2: Constrained RBAC
Añade el uso obligatorio de separación de deberes (Separation of Duties). Sirve para controlar escenarios de conflictos de interés. - RBAC3: Full
